Systems and methods for protecting a service mesh from external attacks on exposed software vulnerabilities

ABSTRACT

Systems and method handling software vulnerabilities in service meshes can include receiving information on software vulnerabilities from external feeds. From a services catalog which maintains data associated with service instances supported by a service mesh, one or more vulnerable service instances supported by the service mesh are identified. Notifications are provided to sidecar proxies associated with vulnerable service instances. The notifications include criteria such as criticality levels and categories associated with the software vulnerabilities. Based on destination policies for the vulnerable service instances, instructions are provided to the sidecar proxies to trip circuit breakers associated with the vulnerable service instances and thus prevent further access and cascading impact of the software vulnerabilities. The software vulnerabilities are reported to an orchestration system for the service mesh and a fix or different version of the vulnerable service instance is installed where possible.

TECHNICAL FIELD

The subject matter of this disclosure relates in general to the field ofcloud computing, and more particularly to protecting a service mesh in acloud-native infrastructure from software vulnerabilities in serviceinstances supported by the service mesh.

BACKGROUND

With the increasing popularity of cloud-native applications, the use ofa service mesh for supporting application services (or “microservices”)such as traffic management, security, load balancing, etc., on thecloud-native applications are on the rise. A service mesh may utilizesoftware components controlled by application programming interfaces(APIs), without reliance on discrete hardware appliances. The servicemesh architecture may use open source technologies and may expose thecloud-native applications to software vulnerabilities. Cloud-nativeenvironments may include a large number of software services (e.g.,hundreds or thousands of microservices executing at any given time, withinstances of the microservices based on different software versions). Insome cases, different software services may be chained together toexecute applications. In such environments, identifying the softwareservices which may be impacted when a software vulnerability is detectedis very challenging. This problem is exacerbated with an increasingnumber of software services, some of which may have different versionssupported by the cloud-native environment. Furthermore, isolatingcritical software services and preventing them from interacting with thepotentially vulnerable or compromised software services is yet anotherchallenge.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the disclosure can be obtained, a moreparticular description of the principles briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only exemplary embodiments of the disclosure and are nottherefore to be considered to be limiting of its scope, the principlesherein are described and explained with additional specificity anddetail through the use of the accompanying drawings in which:

FIG. 1 illustrates a topology of an enterprise network in accordancewith some examples;

FIG. 2 illustrates a logical architecture for an enterprise network inaccordance with some examples;

FIG. 3 illustrates a service mesh in coordination with external feedsfor obtaining information about software vulnerabilities in accordancewith some examples;

FIG. 4 illustrates a process of identifying and handling softwarevulnerabilities in service instances of a service mesh in accordancewith some examples;

FIG. 5 illustrates an example method for handling softwarevulnerabilities in a service mesh in accordance with some examples;

FIG. 6 illustrates an example network device in accordance with variousexamples; and

FIG. 7 illustrates an example computing device architecture, inaccordance with some examples.

DETAILED DESCRIPTION

Various embodiments of the disclosure are discussed in detail below.While specific implementations are discussed, it should be understoodthat this is done for illustration purposes only. A person skilled inthe relevant art will recognize that other components and configurationsmay be used without parting from the spirit and scope of the disclosure.

Overview

Additional features and advantages of the disclosure will be set forthin the description which follows, and in part will be obvious from thedescription, or can be learned by practice of the herein disclosedprinciples. The features and advantages of the disclosure can berealized and obtained by means of the instruments and combinationsparticularly pointed out in the appended claims. These and otherfeatures of the disclosure will become more fully apparent from thefollowing description and appended claims, or can be learned by thepractice of the principles set forth herein.

Disclosed herein are systems, methods, and computer-readable media forschemes according to which, software vulnerabilities in service meshesmay be effectively identified and handled. In some examples, a method isprovided. The method can involve receiving information on one or moresoftware vulnerabilities from one or more external feeds, andidentifying, from a services catalog, one or more vulnerable serviceinstances supported by a service mesh, the one or more vulnerableservice instances identified as having one or more softwarevulnerabilities based on the received information, wherein the servicescatalog comprises data associated with one or more service instancessupported by the service mesh. The method can further include providingat least one notification to at least one sidecar proxy associated withat least one vulnerable service instance of the one or more vulnerableservice instances, the at least one notification comprising one or morecriteria associated with one or more software vulnerabilities of the atleast one vulnerable service instance.

In some examples of the method, the one or more criteria can compriseone or more criticality levels associated with the one or more softwarevulnerabilities of the at least one vulnerable service instance. In someexamples of the method, the one or more criticality levels are based ona common vulnerability scoring system (CVSS). In some examples of themethod, the one or more criteria comprise one or more categoriesassociated with the one or more software vulnerabilities of the at leastone vulnerable service instance.

In some examples of the method, the at least one notification furthercomprises an instruction to the at least one sidecar proxy to trip acircuit breaker associated with the at least one vulnerable serviceinstance. In some examples of the method, the instruction is based onthe one or more criteria and one or more destination policies for the atleast one vulnerable service instance. In some examples of the method,tripping the circuit breaker prevents access to the at least onevulnerable service instance and causes requests to access the at leastone vulnerable service instance to be returned with a message indicatingthat the at least one vulnerable service instance is unavailable.

In some examples, the method can further include reporting the one ormore software vulnerabilities of the at least one vulnerable serviceinstance to an orchestration system for the service mesh. In someexamples of the method, the one or more external feeds comprise one ormore cloud consortia, blockchains, or Product Security Incident ResponseTeam (PSIRT) bulletin boards.

In some examples, the method can further include determining a fix tothe one or more software vulnerabilities of the at least one vulnerableservice instance and providing the fix to the at least one sidecarproxy. In some examples of the method, the fix comprises a version ofthe at least one service instance unaffected by the one or more softwarevulnerabilities of the at least one vulnerable service instance. In someexamples of the method, the fix comprises a version of the at least onevulnerable service instance including a patch for the one or moresoftware vulnerabilities of the at least one vulnerable serviceinstance.

In some examples of the method, the data associated with one or moreservice instances in the services catalog comprises one or more of anoperating system version, software version, or dependency packages ofthe one or more service instances.

In some examples, a system is provided. The system can comprise one ormore processors and a non-transitory computer-readable storage mediumcontaining instructions which, when executed on the one or moreprocessors, cause the one or more processors to perform operations. Theoperations can include receiving information on one or more softwarevulnerabilities from one or more external feeds, and identifying, from aservices catalog, one or more vulnerable service instances supported bya service mesh, the one or more vulnerable service instances identifiedas having one or more software vulnerabilities based on the receivedinformation, wherein the services catalog comprises data associated withone or more service instances supported by the service mesh. Theoperations can further include providing at least one notification to atleast one sidecar proxy associated with at least one vulnerable serviceinstance of the one or more vulnerable service instances, the at leastone notification comprising one or more criteria associated with one ormore software vulnerabilities of the at least one vulnerable serviceinstance.

In some examples of the system, the one or more criteria comprise one ormore criticality levels associated with the one or more softwarevulnerabilities of the at least one vulnerable service instance. In someexamples of the system, the one or more criticality levels are based ona common vulnerability scoring system (CVSS). In some examples of thesystem, the one or more criteria comprise one or more categoriesassociated with the one or more software vulnerabilities of the at leastone vulnerable service instance.

In some examples of the system, the at least one notification furthercomprises an instruction to the at least one sidecar proxy to trip acircuit breaker associated with the at least one vulnerable serviceinstance. In some examples of the system, the operations furthercomprise reporting the one or more software vulnerabilities of the atleast one vulnerable service instance to an orchestration system for theservice mesh. In some examples of the system, the operations furthercomprise determining a fix to the one or more software vulnerabilitiesof the at least one vulnerable service instance and providing the fix tothe at least one sidecar proxy.

Description of Example Embodiments

Disclosed herein are systems, methods, and computer-readable media forschemes according to which, real time and original traffic streamstransmitted between source and destination nodes may be selectivelychosen, headers thereof truncated, and transmitted to a networkcontroller for network analysis, without interfering with the real timeand original traffic streams being forwarded to their destinations. Someexample advantages of using the real time and original traffic streamsare the reduction of load in both control and data planes as well assignificant reduction in complexity of performing network monitoring,performance measurement and detecting network impairments.

Cloud-native environments can include cloud computing systems whichemploy containers. Containers are a lightweight, efficient and standardway for applications to move between different environments (e.g., anon-premises site, a remote site, etc.) and run independently. In someimplementations, a container may hold all the information and data whichmay be needed for running an application. For example, code, run time,system tools, libraries and settings for an application may be packagedin the container. The use of containers makes it possible to builddistributed applications for cloud-native environments.

Different software services may be supported by cloud-nativeapplications. The term “microservice” refers to a software service whichmay be used for building a distributed application using containers. Amicroservice architecture treats different functions of a cloud-nativeapplication (e.g., security, traffic management, etc.) as independentservices that can be altered, updated, or taken down without affectingother applications in the cloud-native environment. In some examples,microservices may be built around business capabilities of a companyutilizing a cloud-native environment, and the microservices may beindependently deployable using fully automated deployment machinery.

Based on their infrastructure, the cloud-native applications may utilizevarious software services for functions such as load balancing, trafficmanaging, routing, health monitoring, security policies, service anduser authentication, protection against intrusion, distributed denial ofservice (DDoS) attacks, etc. In cloud-native applications, thesesoftware services may be implemented using microservices constructs,which may involve the provision of a large number (e.g., hundreds orthousands) of containers. Discrete hardware appliances for managingthese large numbers of containers are not practical, and hence, a“service mesh” is employed to manage and deliver the microservices whichmay be integrated within a compute cluster of a cloud-nativeenvironment, for example. The service mesh utilizes applicationprogramming interfaces (APIs) which do not need hardware appliances fortheir implementation. In some examples, the service mesh may deliver apervasive layer of services across all environments that containerizedapplications and microservices can be connected to.

Thus, the service mesh may be used to deliver services such as trafficmanagement, security, and observability to container-based microservicesapplications directly within the compute cluster. Since the service meshprovides monitoring, scalability, and high availability services throughsoftware components controlled by APIs instead of using discretehardware appliances, the flexible framework of the service mesh reducesthe operational complexity associated with modern, distributedapplications. For example, the service mesh delivers applicationservices, such as load balancing without requiring an expensive andchallenging alternative such as a physical hardware appliance loadbalancer at each location and/or each server utilized by the cloudinfrastructure.

A service mesh may be implemented using an array of network proxiesalongside the containers. Each proxy, referred to as a “sidecar proxy”,serves as a gateway to interactions that occur between containers. Asidecar proxy assists in spreading compute load across the service meshand directing a request to the appropriate downstream container that canserve the request. A central controller may orchestrate the connectionsin the service mesh, and a control plane may be configured to monitorthe service traffic flowing between sidecar proxies. The control planemay deliver access control policies and collects performance metrics tobe provided to the orchestrator. The orchestrator may also integratewith platforms such as open-source systems for automating the deploymentand management of containerized applications.

In a service mesh infrastructure, each microservice may be developed,deployed and managed independently, as noted above. For example, newfeatures and updates to a microservice may be delivered to the servicemesh, sometimes in a rapid and incremental fashion, such that newerversions of microservices may be continually integrated into thecloud-native platform. Micro service-based applications developed inthis manner are extremely dynamic as they can be updated and deployedhundreds of times a day, for example. However, given the independentmanner in which the numerous microservices, and versions thereof, may bedeveloped and deployed, there may be vulnerabilities in one or more ofthese microservices. Some vulnerabilities may be severe and causewidespread disruption across the service mesh, while others may be lesssevere and contained. Identifying the vulnerabilities, recognizingpotential containers which may be affected, and taking action based onthe criticalities of these vulnerabilities is a challenge. The followingsections describe systems and methods for protecting an example servicemesh from software vulnerabilities.

FIG. 1 illustrates an example of a topology of an enterprise network 100which may be configured according to aspects of this disclosure. Forexample, the enterprise network 100 may include a wired network whosetraffic may be monitored according to example techniques herein. In oneexample, the enterprise network 100 may provide intent-based networking.It should be understood that, for the enterprise network 100 and anynetwork discussed herein, there can be additional or fewer nodes,devices, links, networks, or components in similar or alternativeconfigurations. Example embodiments with different numbers and/or typesof endpoints, nodes, cloud components, servers, software components,devices, virtual or physical resources, configurations, topologies,services, appliances, or deployments are also contemplated herein.Further, the enterprise network 100 can include any number or type ofresources, which can be accessed and utilized by endpoints or networkdevices. The illustrations and examples provided herein are for clarityand simplicity.

In this example, the enterprise network 100 includes a management cloud102 and a network fabric 120. Although shown as an external network orcloud to the network fabric 120 in this example, the management cloud102 may alternatively or additionally reside on the premises of anorganization or in a colocation center (in addition to being hosted by acloud provider or similar environment). The management cloud 102 canprovide a central management plane for building and operating thenetwork fabric 120. The management cloud 102 can be responsible forforwarding configuration and policy distribution, as well as devicemanagement and analytics. The management cloud 102 can comprise one ormore network controller appliances 104, one or more authentication,authorization, and accounting (AAA) appliances 106, one or more wirelesslocal area network controllers (WLCs) 108, and one or more fabriccontrol plane nodes 110. In other embodiments, one or more elements ofthe management cloud 102 may be co-located with the network fabric 120.

The network controller appliance(s) 104 can function as the command andcontrol system for one or more network fabrics, and can house automatedworkflows for deploying and managing the network fabric(s). The networkcontroller appliance(s) 104 can include automation, design, policy,provisioning, and assurance capabilities, among others, as discussedfurther below with respect to FIG. 2. In some examples, one or moreCisco Digital Network Architecture (Cisco DNA™) appliances can operateas the network controller appliance(s) 104.

The AAA appliance(s) 106 can control access to computing resources,facilitate enforcement of network policies, audit usage, and provideinformation necessary to bill for services. The AAA appliance caninteract with the network controller appliance(s) 104 and with databasesand directories containing information for users, devices, things,policies, billing, and similar information to provide authentication,authorization, and accounting services. In some embodiments, the AAAappliance(s) 106 can utilize Remote Authentication Dial-In User Service(RADIUS) or Diameter to communicate with devices and applications. Insome embodiments, one or more Cisco® Identity Services Engine (ISE)appliances can operate as the AAA appliance(s) 106.

The WLC(s) 108 can support fabric-enabled access points attached to thenetwork fabric 120, handling traditional tasks associated with a WLC aswell as interactions with the fabric control plane for wireless endpointregistration and roaming. In some embodiments, the network fabric 120can implement a wireless deployment that moves data-plane termination(e.g., Virtual Extensible Local Area Network or “VXLAN”) from acentralized location (e.g., with previous overlay Control andProvisioning of Wireless Access Points (CAPWAP) deployments) to anaccess point/fabric edge node. This can enable distributed forwardingand distributed policy application for wireless traffic while retainingthe benefits of centralized provisioning and administration. In someembodiments, one or more Cisco® Wireless Controllers, Cisco® WirelessLAN, and/or other Cisco DNA™-ready wireless controllers can operate asthe WLC(s) 108.

The network fabric 120 can comprise fabric border nodes 122A and 122B(collectively, 122), fabric intermediate nodes 124A-D (collectively,124), and fabric edge nodes 126A-F (collectively, 126). Although thefabric control plane node(s) 110 are shown to be external to the networkfabric 120 in this example, in other embodiments, the fabric controlplane node(s) 110 may be co-located with the network fabric 120. Inembodiments where the fabric control plane node(s) 110 are co-locatedwith the network fabric 120, the fabric control plane node(s) 110 maycomprise a dedicated node or set of nodes or the functionality of thefabric control node(s) 110 may be implemented by the fabric border nodes122.

The fabric control plane node(s) 110 can serve as a central database fortracking all users, devices, and things as they attach to the networkfabric 120, and as they roam around. The fabric control plane node(s)110 can allow network infrastructure (e.g., switches, routers, WLCs,etc.) to query the database to determine the locations of users,devices, and things attached to the fabric instead of using a flood andlearn mechanism. In this manner, the fabric control plane node(s) 110can operate as a single source of truth about where every endpointattached to the network fabric 120 is located at any point in time. Inaddition to tracking specific endpoints (e.g., /32 address for IPv4,/128 address for IPv6, etc.), the fabric control plane node(s) 110 canalso track larger summarized routers (e.g., IP/mask). This flexibilitycan help in summarization across fabric sites and improve overallscalability.

The fabric border nodes 122 can connect the network fabric 120 totraditional Layer 3 networks (e.g., non-fabric networks) or to differentfabric sites. The fabric border nodes 122 can also translate context(e.g., user, device, or thing mapping and identity) from one fabric siteto another fabric site or to a traditional network. When theencapsulation is the same across different fabric sites, the translationof fabric context is generally mapped 1:1. The fabric border nodes 122can also exchange reachability and policy information with fabriccontrol plane nodes of different fabric sites. The fabric border nodes122 also provide border functions for internal networks and externalnetworks. Internal borders can advertise a defined set of known subnets,such as those leading to a group of branch sites or to a data center.External borders, on the other hand, can advertise unknown destinations(e.g., to the Internet similar in operation to the function of a defaultroute).

The fabric intermediate nodes 124 can operate as pure Layer 3 forwardersthat connect the fabric border nodes 122 to the fabric edge nodes 126and provide the Layer 3 underlay for fabric overlay traffic.

The fabric edge nodes 126 can connect endpoints to the network fabric120 and can encapsulate/decapsulate and forward traffic from theseendpoints to and from the network fabric. The fabric edge nodes 126 mayoperate at the perimeter of the network fabric 120 and can be the firstpoints for attachment of users, devices, and things and theimplementation of policy. In some embodiments, the network fabric 120can also include fabric extended nodes (not shown) for attachingdownstream non-fabric Layer 2 network devices to the network fabric 120and thereby extend the network fabric. For example, extended nodes canbe small switches (e.g., compact switch, industrial Ethernet switch,building automation switch, etc.) which connect to the fabric edge nodesvia Layer 2. Devices or things connected to the fabric extended nodescan use the fabric edge nodes 126 for communication to outside subnets.

In this example, the network fabric can represent a single fabric sitedeployment which can be differentiated from a multi-site fabricdeployment.

In some examples, all subnets hosted in a fabric site can be provisionedacross every fabric edge node 126 in that fabric site. For example, ifthe subnet 10.10.10.0/24 is provisioned in a given fabric site, thissubnet may be defined across all of the fabric edge nodes 126 in thatfabric site, and endpoints located in that subnet can be placed on anyfabric edge node 126 in that fabric. This can simplify IP addressmanagement and allow deployment of fewer but larger subnets. In someembodiments, one or more Cisco® Catalyst switches, Cisco Nexus®switches, Cisco Meraki® MS switches, Cisco® Integrated Services Routers(ISRs), Cisco® Aggregation Services Routers (ASRs), Cisco® EnterpriseNetwork Compute Systems (ENCS), Cisco® Cloud Service Virtual Routers(CSRvs), Cisco Integrated Services Virtual Routers (ISRvs), CiscoMeraki® MX appliances, and/or other Cisco DNA-ready™ devices can operateas the fabric nodes 122, 124, and 126.

The enterprise network 100 can also include wired endpoints 130A, 130C,130D, and 130F and wireless endpoints 130B and 130E (collectively, 130).The wired endpoints 130A, 130C, 130D, and 130F can connect by wire tofabric edge nodes 126A, 126C, 126D, and 126F, respectively, and thewireless endpoints 130B and 130E can connect wirelessly to wirelessaccess points 128B and 128E (collectively, 128), respectively, which inturn can connect by wire to fabric edge nodes 126B and 126E,respectively. In some embodiments, Cisco Aironet® access points, CiscoMeraki® MR access points, and/or other Cisco DNA™-ready access pointscan operate as the wireless access points 128.

The endpoints 130 can include general purpose computing devices (e.g.,servers, workstations, desktop computers, etc.), mobile computingdevices (e.g., laptops, tablets, mobile phones, etc.), wearable devices(e.g., watches, glasses or other head-mounted displays (HMDs), eardevices, etc.), and so forth. The endpoints 130 can also includeInternet of Things (IoT) devices or equipment, such as agriculturalequipment (e.g., livestock tracking and management systems, wateringdevices, unmanned aerial vehicles (UAVs), etc.); connected cars andother vehicles; smart home sensors and devices (e.g., alarm systems,security cameras, lighting, appliances, media players, HVAC equipment,utility meters, windows, automatic doors, door bells, locks, etc.);office equipment (e.g., desktop phones, copiers, fax machines, etc.);healthcare devices (e.g., pacemakers, biometric sensors, medicalequipment, etc.); industrial equipment (e.g., robots, factory machinery,construction equipment, industrial sensors, etc.); retail equipment(e.g., vending machines, point of sale (POS) devices, Radio FrequencyIdentification (RFID) tags, etc.); smart city devices (e.g., streetlamps, parking meters, waste management sensors, etc.); transportationand logistical equipment (e.g., turnstiles, rental car trackers,navigational devices, inventory monitors, etc.); and so forth.

In some examples, the network fabric 120 can support wired and wirelessaccess as part of a single integrated infrastructure such thatconnectivity, mobility, and policy enforcement behavior are similar orthe same for both wired and wireless endpoints. This can bring a unifiedexperience for users, devices, and things that is independent of theaccess media.

In integrated wired and wireless deployments, control plane integrationcan be achieved with the WLC(s) 108 notifying the fabric control planenode(s) 110 of joins, roams, and disconnects by the wireless endpoints130 such that the fabric control plane node(s) can have connectivityinformation about both wired and wireless endpoints in the networkfabric 120, and can serve as the single source of truth for endpointsconnected to the network fabric. For data plane integration, the WLC(s)108 can instruct the fabric wireless access points 128 to form a VXLANoverlay tunnel to their adjacent fabric edge nodes 126. The AP VXLANtunnel can carry segmentation and policy information to and from thefabric edge nodes 126, allowing connectivity and functionality identicalor similar to that of a wired endpoint. When the wireless endpoints 130join the network fabric 120 via the fabric wireless access points 128,the WLC(s) 108 can onboard the endpoints into the network fabric 120 andinform the fabric control plane node(s) 110 of the endpoints' MediaAccess Control (MAC) addresses. The WLC(s) 108 can then instruct thefabric wireless access points 128 to form VXLAN overlay tunnels to theadjacent fabric edge nodes 126. Next, the wireless endpoints 130 canobtain IP addresses for themselves via Dynamic Host ConfigurationProtocol (DHCP). Once that completes, the fabric edge nodes 126 canregister the IP addresses of the wireless endpoint 130 to the fabriccontrol plane node(s) 110 to form a mapping between the endpoints' MACand IP addresses, and traffic to and from the wireless endpoints 130 canbegin to flow.

FIG. 2 illustrates an example of a logical architecture 200 for anenterprise network (e.g., the enterprise network 100). One of ordinaryskill in the art will understand that, for the logical architecture 200and any system discussed in the present disclosure, there can beadditional or fewer component in similar or alternative configurations.The illustrations and examples provided in the present disclosure arefor conciseness and clarity. Other examples may include differentnumbers and/or types of elements but one of ordinary skill the art willappreciate that such variations do not depart from the scope of thepresent disclosure. In this example, the logical architecture 200includes a management layer 202, a controller layer 220, a network layer230 (such as embodied by the network fabric 120), a physical layer 240(such as embodied by the various elements of FIG. 1), and a sharedservices layer 250.

The management layer 202 can abstract the complexities and dependenciesof other layers and provide a user with tools and workflows to manage anenterprise network (e.g., the enterprise network 100). The managementlayer 202 can include a user interface 204, design functions 206, policyfunctions 208, provisioning functions 210, assurance functions 212,platform functions 214, and base automation functions 216. The userinterface 204 can provide a user a single point to manage and automatethe network. The user interface 204 can be implemented within a webapplication/web server accessible by a web browser and/or anapplication/application server accessible by a desktop application, amobile app, a shell program or other command line interface (CLI), anApplication Programming Interface (e.g., restful state transfer (REST),Simple Object Access Protocol (SOAP), Service Oriented Architecture(SOA), etc.), and/or other suitable interface in which the user canconfigure network infrastructure, devices, and things that arecloud-managed; provide user preferences; specify policies, enter data;review statistics; configure interactions or operations; and so forth.The user interface 204 may also provide visibility information, such asviews of a network, network infrastructure, computing devices, andthings. For example, the user interface 204 can provide a view of thestatus or conditions of the network, the operations taking place,services, performance, a topology or layout, protocols implemented,running processes, errors, notifications, alerts, network structure,ongoing communications, data analysis, and so forth.

The design functions 206 can include tools and workflows for managingsite profiles, maps and floor plans, network settings, and IP addressmanagement, among others. The policy functions 208 can include tools andworkflows for defining and managing network policies. The provisioningfunctions 210 can include tools and workflows for deploying the network.The assurance functions 212 can use machine learning and analytics toprovide end-to-end visibility of the network by learning from thenetwork infrastructure, endpoints, and other contextual sources ofinformation. The platform functions 214 can include tools and workflowsfor integrating the network management system with other technologies.The base automation functions 216 can include tools and workflows tosupport the policy functions 208, the provisioning functions 210, theassurance functions 212, and the platform functions 214.

In some examples, the design functions 206, the policy functions 208,the provisioning functions 210, the assurance functions 212, theplatform functions 214, and the base automation functions 216 can beimplemented as microservices in which respective software functions areimplemented in multiple containers communicating with each rather thanamalgamating all tools and workflows into a single software binary. Eachof the design functions 206, policy functions 208, provisioningfunctions 210, assurance functions 212, and platform functions 214 canbe viewed as a set of related automation microservices to cover thedesign, policy authoring, provisioning, assurance, and cross-platformintegration phases of the network lifecycle. The base automationfunctions 214 can support the top-level functions by allowing users toperform certain network-wide tasks.

FIG. 3 illustrates an example topology of a network 300 configured toimplement aspects of this disclosure. The network 300 may be anenterprise network for supporting cloud-native applications. In someaspects, the network 300 may be include an example implementation of theenterprise network 100 of FIG. 1 whose logical architecture 200 wasdescribed with reference to FIG. 2 above.

For example, the network 300 illustrates a service mesh 302 which mayprovisioned with a network fabric such as the network fabric 120 ofFIG. 1. The service mesh 302 may be a software defined network (SDN) andinclude a centralized control plane 310 that configures the data planeof the service mesh 302. The service mesh 302 provides an infrastructurelayer for governing service-to-service communications. The service mesh302 includes an array 322 of network proxies. Among the various networkproxies which the array 322 may include, sidecar proxies 324 a-c areillustrated, and will be explained in more detail below.

As will be understood by one skilled in the art, enterprise networks mayuse proxies for implementing security measures and managing accesses toservices. For example, if a user in an office environment of a companyrequests a webpage from a computer in the office, then the request mayfirst be received by a web proxy of the company which may check therequest for security issues. Once the security measures implemented bythe web proxy are cleared, then the request may be sent to an externalserver that hosts the web page. When the web page is returned back tothe computer in response to the request, the web proxy may once againcheck the content in the web page being returned for security issues,and then the proxy returns the web page and its contents of the web pageto the user. In the service mesh 302, requests are routed betweenmicroservices through proxies in their own infrastructure layer. Forthis reason, individual proxies that make up a service mesh are referredto as sidecars or sidecar proxies, since they run alongside eachservice, rather than within them. The sidecar proxies 324 a-c areexamples of such sidecar proxies which may be present in the servicemesh 302.

A sidecar proxy may handle access and security measures for one or moreservice instances to which the sidecar proxy is paired. For example,service instances 328 a-c are shown in FIG. 3, paired with respectivesidecar proxies 324 a-c. Further, a service instance and its pairedsidecar may proxy share a container. For example, containers 330 a-c areshown, wherein each container 330 a-c may be shared by a respectiveservice instance 328 a-c and sidecar proxy 324 a-c. The sidecar proxies324 a-c may handle communication with service instances of othercontainers. For example, the sidecar proxy 324 a of the container 330 amay handle communication of the service instance 328 a with the serviceinstance 328 b of the container 330 b. The sidecar proxies 324 a-c mayalso support capabilities such as discovery of service instances, loadbalancing, authentication and authorization, secure communications,etc., in the service mesh 302. The service instances 328 a-c may bemicroservices. As previously explained, the microservices may be aspecialization of an implementation approach for service-orientedarchitectures (SOA) used to build flexible, independently deployablesoftware systems.

The control plane 310 may handle the control functions for the servicemesh 302, as previously mentioned. For example, the control plane 310may install and maintain policy and configuration on the serviceinstances 328 a-c (e.g., through respective sidecar proxies 324 a-c).The control plane 310 may instructs the sidecar proxies 324 a-c withdynamic updates to these policies and configurations in some examples.Accordingly, the control plane 310 may include different modules forcarrying out these functions. For example, the control plane 310 mayinclude a policy module 312 for defining and managing network policies,traffic policies, etc. The control plane 310 may also include a loadbalancer 314 for implementing load balancing schemes for balancing thetraffic and workloads in the service mesh 302. One or more other moduleswhich may be present in the control plane 310 are generically shown asthe module 316, for performing the one or more control functionsdiscussed with reference to the control layer 220 in FIG. 2, forexample.

In example aspects, the control plane 310 may include a softwarevulnerability processor (SVP) 318 for handling the various functionsrelated to identifying, isolating, and rectifying softwarevulnerabilities, for example. In one or more examples, the SVP 318 (ormore generally, the control plane 310) may be in communication with aservices catalog 320. The services catalog 320 may maintain a catalog ofvarious details, such as the software versions, origin, release date,etc., for the software running in the various service instances 328 a-cof the service mesh 302, for example. Accordingly in some examples, theservices catalog 320 may contain an up to date mapping of the software(and version thereof) and the service instances 328 a-c. The servicescatalog 320 may be updated in one or more manners, which will bedescribed below.

As shown in FIG. 3, the control plane 310 of the service mesh 302 maycommunicate with one or more external entities. Among these, anorchestration system 304 may work in coordination with the service mesh302 for deployment, scaling, and management of containerizedapplications such as in the containers 330 a-c of the service mesh 302.For example, open-source orchestration systems are known in the art forautomatic management or containerized applications. The orchestrationsystem 304 may, among other functions, maintain the state ofworkloads/applications, container images, network resources, etc.

The service mesh 302 may also be in communication with various otherexternal feeds 307, 309, etc., for obtaining information on potentialvulnerabilities in the software executing in its containers 330 a-c, forexample. The software vulnerabilities discussed herein may pertain toany exposures identified in the service instances which may compromiseprivacy, security, efficiency, accuracy, performance, etc., of theservice instances. In some examples, the vulnerabilities may be programbugs, loopholes in service and user authentication, gaps in protectionagainst intrusion, exposure to distributed denial of service (DDoS)attacks, etc. The potential software vulnerabilities may or may not havea fix readily available. A software vulnerability database cloudconsortium 306 may source vulnerability information from variousrepositories and standards, such as the National Vulnerability Database(NVD), Product Security Incident Response Team (PSIRT), etc., and supplythis information on the external feed 307 to the service mesh 302. Thesoftware vulnerability ledger blockchain 308 may provide anotherexternal feed 309 to the service mesh 302 with vulnerabilities obtainedfrom blockchain ledgers and other distributed ledgers, for example.Although not exhaustively shown and described, various other suchexternal feeds may provide information to the service mesh 302 about anysoftware vulnerabilities which have been identified in the industry,publicly known, or sourced from private entities.

In one or more examples, the control plane 310, or more specifically,the SVP 318 may interact with these external feeds 307, 309, etc., andgather software vulnerability and remediation information. In someexamples, the SVP 318 may implement the following processes detectingvulnerabilities which may affect the service mesh 302. The SVP 318 maymonitor the external feeds 307, 309 and consult the services catalog 320to determine if any vulnerability is reported on the external feeds 307,309 which may affect one or more services in the services catalog 320.Further, as and when any new services are added in the service mesh 302or service discovery functions identify new services in the service mesh302, the SVP 318 may update the services catalog 320 and monitor theexternal feeds 307, 309 to determine if any new or updated informationadded to the services catalog 320 may have vulnerabilities reported bythe external feeds 307, 309.

In one or more examples, upon identifying a software vulnerability inone or more services maintained in the services catalog 320, the SVP 318may obtain a complete Common Vulnerabilities and Exposures (CVE)information. The CVE information may include, among other things, theidentity and the criticality of the vulnerability. In one example, theidentity may reveal a specific service instance 328 a of the serviceinstances 328 a-c.

In some examples, an industry standard scoring system, such as a CommonVulnerability Scoring System (CVSS) may be used to classify thecriticality of the identified vulnerability. Using such a scoring systemallows handling of different vulnerabilities based on their severitylevels. While any scoring system or classification system may be used,the CVSS, for example, provides a way to capture the principalcharacteristics of a vulnerability and produce a numerical scorereflecting the severity of the vulnerability. The numerical score canthen be translated into a qualitative representation (e.g., low, medium,high, and critical) to help in assessing and prioritizing the handlingof the vulnerability.

Further, in some aspects, it is possible to identify differentcategories of the vulnerabilities. For example, the vulnerability may becategorized as being database related, messaging related, memory relatedetc.

The CVE obtained by the SVP 318 may further include a determination ofsymptoms and remedies associated with the detected vulnerability. Anypolicies about handling the detected vulnerabilities may also bedetermined. Based on any one or more of the above criteria such as theidentity of the vulnerable service instances, the severity of thevulnerability, the category, the policies, etc., the SVP may alert oneor more sidecar proxies associated with the vulnerable serviceinstances.

In some examples, the SVP 318 may evaluate the impact of thevulnerability on the identified service instances, e.g., based on theabove criteria, and provide alerts to the sidecar proxies of therespective service instances. In some examples, the SVP 318 may utilizespecific policies for determining whether to alert a sidecar policybased on the above criteria. In an example wherein the policy is basedon criticality levels or a CVSS score, for example, a count of a numberof vulnerabilities that can be tolerated for each criticality level maybe determined by the policy.

For example, if the criticality level is “low” based on a low CVSSscore, for example, then then a particular service instance may tolerateup to a count of 5 vulnerabilities in one illustrative example.Therefore, the sidecar proxy for that service instance need not bealerted until five vulnerabilities are discovered for the serviceinstance. Similarly, in an illustrative example, a count of 2 may beused for a “medium” vulnerability score and a count of 1 for a “high”vulnerability score. However, in an illustrative example, a count of 0may be tolerated for a “critical” vulnerability score, in the sense thatno vulnerabilities are tolerated and the sidecar proxy may be notifiedimmediately if a vulnerability of “critical” vulnerability score isdetected.

In some examples, the SVP 318 may alert a sidecar based on the abovepolicies and one or more identified vulnerabilities. For example, theSVP 318 may alert the sidecar proxy 324 a based on the above policiesand one or more identified vulnerabilities for the service instance 328a. One or more triggers 311 shown in FIG. 3 may represent signaling usedfor transmitting such alerts from the control plane 310 to the sidecarproxies 324 a-c. In some examples, the SVP 318 may provide notificationsof the policy and the vulnerability scores to the sidecar proxies andallow the sidecar proxies to determine what further action to take,based on the counts and the criticality levels.

In some examples, the sidecar proxies may trip circuit breakers fortheir associated service instances upon receiving such an alert ortrigger 311 regarding software vulnerabilities, and based on policiespertaining to the software vulnerabilities. Circuit breakers 326 a-c areillustrated for sidecar proxies 324 a-c. This processes implemented by asidecar proxy for preventing access to a vulnerable service instance andisolating the vulnerable service instance from responding to futurerequests and/or propagating the software vulnerabilities further isreferred to as “tripping a circuit breaker”. This term, “tripping acircuit breaker” is merely used to represent a conceptual analogy to anelectrical system which uses a circuit breaker to minimize downstreamimpact of an electrical fault, but the term “tripping a circuit breaker”does not convey any actual or physical similarities to an electricalsystem or related functions of tripping a circuit breaker. The circuitbreakers may be software constructs which are designed to preventfailures from cascading across the micro service network. Upon trippinga circuit breaker, the circuit breaker transitions to an open mode andthe associated service instance returns a cached (or default) responseto its upstream micro services in some examples. For example, upontripping the circuit breaker 326 a, the sidecar proxy 324 a willautomatically return a “service unavailable” message in response to anyrequests received for the service instance 328 a, and deny access to theservice instance 328 a. In this manner, the sidecar proxy 324 a mayisolate the service instance 328 a upon receiving an alert from the SVP318 that the service instance 328 a has a potential vulnerability of acritical vulnerability score. Thus, further cascading impacts of thevulnerability, e.g., to the service instances 328 b-c of the containers330 b-c may be avoided, for example.

In some examples, the control plane 310, or more specifically, the SVP318 may also export all relevant vulnerability information and anyterminated services information to the orchestrator system 304, usingthe export signal 305. Any new requests which may be directed to thosevulnerable services may be blocked by the orchestration system 304and/or the service mesh 302. Further, new instances of the vulnerableservices will not be spawned.

In some aspects, the SVP 318 may further process the CVE and consultrespective vulnerability databases to determine if there is a softwareversion in the services catalog 320 which has a fix to the identifiedvulnerability in a different version of the same software. For example,if the services catalog 320 indicates availability of a differentversion of the service instance 328 a which does not have thevulnerability (e.g., an existing version which never had thevulnerability or a version which has a patch to the vulnerabilityinstalled), then the SVP 318 may try to revert or roll back to theversion of the service instance 328 a which does not have thevulnerability. In some aspects, the SVP 318 may identify a website(e.g., Uniform Resource Locator or “URL”) or remote server locationwhich may have a version with a fix or a patch for the vulnerabilityavailable and initiate a download of the fixed version or the patch. TheSVP 318 may coordinate with the orchestration system 304 if automaticpatching of software is supported for the vulnerable services, and ifso, the vulnerable service, e.g., the service instance 328 a in theabove example may be automatically fixed and restored. In some examples,the SVP 318 may coordinate with any other build system or alert anadministrator or system for manual intervention for installing a fix.

With reference now to FIG. 4, a process 400 is shown for identifying andprotecting the service mesh 302 from potential attacks on exposedsoftware vulnerabilities.

In various aspects, the process 400 may begin with a step 401 forinitializing the SVP 318 of the control plane 310. In some aspects, theSVP 318 may first be initialized before its first deployment in theprocess 400. In this regard, the SVP 318 may perform processes forservice discovery to determine software versions of all services runningin the service mesh 302. For example, the SVP 318 may discover thevarious service instances 328 a-c in containers 330 a-c and theirrelevant software information such as version, date, origin, etc.,during the initialization process. The SVP 318 may also add hooks in theinfrastructure of the service mesh 302 to get notifications for any newsoftware instantiations/deployments. In some aspects, if the SVP 318 hasalready been initialized in an already existing deployment, then in thestep 401, the SVP 318 may perform a service discovery to determinesoftware versions of all the software instances and determine if any ofthe versions have been updated.

In the step 402, the SVP 318 may build a catalog of the servicesdiscovered in the step 401 for all service instances running in theservice mesh 302. The catalog may be stored and maintained in theservices catalog 320. The services catalog 320 may contain one or moretypes of information about the service instances. For example, theinformation in the services catalog 320 may include one or more of anoperating system (OS) version, software version, dependency packages,etc., associated with the service instances. Other metadata such as arelease date, developer information, license information, etc., may alsobe stored in the services catalog 320.

In the step 404, the SVP 318 may receive notifications ofvulnerabilities from one or more external feeds. For example, theexternal feed 307 may provide vulnerability information obtained fromdatabase cloud consortia. In another example, the external feed 309 mayprovide vulnerability information provided by software vulnerabilityblockchains or other public ledgers. Various other external feeds suchas from the NVD, PSIRT, etc., may also be received by the SVP 318. Uponreceiving each notification of a vulnerability, the SVP 318 obtains theservice instances which may be affected by these vulnerabilities. TheSVP 318 walks through the services catalog 320 to determine if any ofthe service instances in the service mesh 302 match or correspond to theone or more service instances obtained from the notification as beingvulnerable.

In the step 406, the SVP 318 may determine the vulnerability score anddestination policies pertaining to any vulnerabilities identified in theone or more service instances in the step 404. Sidecar proxy 324 a andsidecar proxy 324 b have been illustrated, representatively for serviceinstance A 328 a and service instance B 328 b. In some examples, the SVP318 may provide the vulnerabilities and the policies to the respectivesidecar proxies which may be associated with service instancesidentified as having vulnerabilities.

In the illustrative example shown, the sidecar proxy 324 b is notifiedthat the service instance B 328 b has an identified vulnerability. TheSVP 318 provides information such as the criticality score to theservice instance B 328 b. In some examples, the destination policy forthe service instance B 328 b may also be provided by the SVP 318. Insome examples, the sidecar proxy 324 b may already have the associateddestination policy for service instance B 328 b. The destination policymay define custom metrics or settings for the service instance B 328 bthat the sidecar proxy 324B watches. Examples of the settings include,for each of the criticality scores such as critical, high, medium, low,the associated level of impact. Additionally, the settings may alsoinclude, for each of the criticality scores, the count of the number ofvulnerabilities tolerated for that score. Various other settings may bedefined for each deployment of a service with different restrictions andrules. In some examples, the specific policies and criticality scoresmay be used for tripping circuit breakers of sidecar proxies.

For instance, when the SVP 318 sends notifications in the step 406 tothe sidecar proxy 324 b, the sidecar proxy 324 b may receive thisnotification in the step 408. In the step 408, based on the criticalitylevel and policy, the sidecar proxy 324 b may trip the circuit breaker326 b shown in FIG. 3. In one example, tripping the circuit breaker 326b may be an event which occurs when the SVP 318 notifies the sidecarproxy 324 b that a vulnerability with a critical vulnerability score hasbeen identified for service instance B 328 b, which causes the sidecarproxy 324 b to trip the circuit breaker 326 b immediately, withoutwaiting for a larger count of the vulnerabilities to be received andaccumulated.

In the step 408, upon tripping the circuit breaker 326 b, the sidecarproxy 324 b is configured to automatically deny future requests foraccess to the service instance B 328 b. In some examples, the sidecarproxy 324 b may return a notification such as “Service Unavailable” forany future requests to the service instance B 328 b. This isdemonstrated in the steps 410-412, wherein, when the service instance A328 a sends a new request to access the service instance B 328 b in thestep 410, the sidecar proxy 324 b returns a “Service Unavailable”notification to the service instance A 328 a (or to its sidecar proxy324 a) in the step 412.

Tripping the circuit breaker 326 b on the affected service instance B328 b in this manner as illustrated in the steps 408-412, for example,may efficiently and immediately ensure that all other calling servicesare blocked from accessing the service instance B 328 b. Thus, apotentially cascading impact of the vulnerability identified for theservice instance B 328 b may be prevented.

In some examples, in addition to implementing the above steps ofpreventing access to future requests and returning a “ServiceUnavailable” notification, service discovery can also reflect the statusof the affected services upon tripping the circuit breaker. Forinstance, service discovery processes by the SVP 318 may return a statuswhich reflects that the circuit breaker 326 b has been tripped for thecontainer 330 b which includes the affected service instance B 328 b. Inthis regard, the term, affected services conveys any service instancewhich has been identified as having a vulnerability, and in someexamples, a circuit breaker for the service instance may have beentripped.

In the step 414, the SVP 318 may informs the orchestration system 304 ofthe identified vulnerability in the service instance B 328 b, and thesubsequent events implemented by the sidecar proxy 324 b to trip thecircuit breaker 326 b. The orchestration system 304 may use thisinformation to upgrade or downgrade the service instance B 328 b to adifferent version which is not affected by the vulnerability in someexamples. In some examples, the orchestration system 304 may scaledown/deletes existing containers with vulnerabilities, such as thecontainer 330 b, and deploy new containers with new software versionsfor performing the service instance B.

In some examples, the SVP 318 may determine whether a service similar tothe service instance B 328 b exists in the service mesh 302 (e.g., adifferent version of the service instance B) which is not affected bythe vulnerability. If such a similar service instance is identified,e.g., from the services catalog 320, then the pertinent information maybe shared with the sidecar proxy 324 b, for example. The sidecar proxy324 b can act as a proxy and redirect calls to the service instance B328 b to its safer similar service in this example.

In some examples, the SVP 318 may determine if there is a softwareversion in the services catalog 320 which has a fix to the identifiedvulnerability in a different version of the same software. For example,if the services catalog 320 indicates availability of a differentversion of the service instance B 328 b which does not have thevulnerability (e.g., an existing version which never had thevulnerability or a version which has a patch to the vulnerabilityinstalled), then the SVP 318 may try to revert or roll back to theversion of the service instance B 328 b which does not have thevulnerability. In some aspects, the SVP 318 may identify a website(e.g., Uniform Resource Locator or “URL”) or remote server locationwhich may have a version with a fix or a patch for the vulnerabilityavailable and initiate a download of the fixed version or the patch. TheSVP 318 may coordinate with the orchestration system 304 if automaticpatching of software is supported for the vulnerable services, and ifso, the vulnerable service, e.g., the service instance B 328 b in theabove example may be automatically fixed and restored. In some examples,the SVP 318 may coordinate with any other build system or alert anadministrator or system for manual intervention for installing a fix.

Accordingly, aspects of this disclosure are directed to efficienttechniques for protecting a service mesh from potential attacks onservice instances which may be exposed software vulnerabilities. In someexamples, the identification of software instances which may bevulnerable may be based on coordination with external feeds such asblockchains or other consortia.

Having described example systems and concepts, the disclosure now turnsto the method 500 illustrated in FIG. 5. The steps outlined herein areexamples and can be implemented in any combination thereof, includingcombinations that exclude, add, or modify certain steps. The method 500may be directed to identifying and protecting a service mesh such as theservice mesh 302 from software vulnerabilities in service instancessupported therein.

At the step 502, the method 500 can involve receiving information on oneor more software vulnerabilities from one or more external feeds. Forinstance, the SVP 318 may receive information on one or more softwarevulnerabilities through the external feeds 307, 309 from one or morecloud consortia, blockchains, or Product Security Incident Response Team(PSIRT) bulletin boards, etc.

At the step 504, the method 500 can involve identifying, from a servicescatalog, one or more vulnerable service instances supported by a servicemesh, the one or more vulnerable service instances identified as havingone or more software vulnerabilities based on the received information,wherein the services catalog comprises data associated with one or moreservice instances supported by the service mesh. For example, theservices catalog 320 may maintain data associated with one or moreservice instances supported by the service mesh. The data associatedwith one or more service instances in the services catalog 320 caninclude, for example, one or more of an operating system version,software version, or dependency packages of the one or more serviceinstances. In one or more examples, the one or more vulnerable serviceinstances may be identified as having one or more softwarevulnerabilities based on the received information from the externalfeeds. For example, the SVP 318 may consult the services catalog 320 anddetermine if any of the service instances with software vulnerabilitiesreported on the external feeds have a matching entry in the servicescatalog 320.

At the step 506, the method 500 can include providing at least onenotification to at least one sidecar proxy associated with at least onevulnerable service instance of the one or more vulnerable serviceinstances, the at least one notification comprising one or more criteriaassociated with one or more software vulnerabilities of the at least onevulnerable service instance. The at least one notification can includeone or more criteria associated with software vulnerabilities of thevulnerable service instance. For example, the SVP 318 may provide anotification or trigger 311 to the sidecar proxy 324 b regardingvulnerabilities in the service instance B 328 b, as discussed in FIG. 3.The one or more criteria in the notification can include one or morecriticality levels associated with the software vulnerabilities of theservice instance B 328 b. For example, the one or more criticalitylevels may be based on a common vulnerability scoring system (CVSS) andindicate numerical scores or criticality level indications such as low,medium, high, and critical. In some examples, the one or more criteriacan also comprise one or more categories associated with the softwarevulnerabilities of the vulnerable service instance. For example, the oneor more categories may indicate whether the software vulnerabilities aredatabase related, messaging related, memory related, etc.

In some examples, the notification may further include an instruction tothe at least one sidecar proxy to trip a circuit breaker associated withthe at least one vulnerable service instance. For example, thenotification in the step 406 to the service instance B 328 b may includean instruction to trip the circuit breaker 326 b. In some examples, theinstruction may be based on the one or more criteria and one or moredestination policies for the vulnerable service instance. For instance,destination policies for the service instance B 328 b may indicate thelevel of impact for the various criticality levels and also a count ofthe number vulnerabilities which may be tolerated at the differentcriticality levels by service instance B 328 b.

In some examples, tripping the circuit breaker may prevent access to theat least one service instance and cause requests to access the at leastone service instance to be returned with a message indicating that theservice instance is unavailable. For example, upon tripping the circuitbreaker 326 b in the step 408, the sidecar proxy 328 b may preventaccess to the service instance B 328 b and cause requests such as thenew request in the step 410 to access the service instance B 328 b to bereturned with a message in the step 412 indicating that the serviceinstance B 328 b is unavailable.

In some examples, the one or more software vulnerabilities of the atleast one vulnerable service instance may be reported to anorchestration system for the service mesh. For example, the SVP 318 mayreport the software vulnerabilities of the service instance B 328 b toorchestration system 304 in the step 414. In various aspects, the method500 may further involve determining a fix to the one or more softwarevulnerabilities of the at least one vulnerable service instance andproviding the fix to the at least one sidecar proxy. In some examples,the fix comprises a version of the at least one vulnerable serviceinstance free from the one or more software vulnerabilities of the atleast one vulnerable service instance. In some examples, the fixcomprises a version of the at least one vulnerable service instance witha patch for the one or more software vulnerabilities of the at least onevulnerable service instance. For example, the SVP 318 may obtain a fixbased on a patch or rolling back to a different (clean) version of theservice instance B 328 b as discussed in the foregoing sections.

FIG. 6 illustrates an example network device 600 suitable forimplementing the aspects according to this disclosure. In some examples,the control plane 310 and/or the SVP 318 may be implemented according tothe configuration of the network device 600. The network device 600includes a central processing unit (CPU) 604, interfaces 602, and aconnection 610 (e.g., a PCI bus). When acting under the control ofappropriate software or firmware, the CPU 604 is responsible forexecuting packet management, error detection, and/or routing functions.The CPU 604 preferably accomplishes all these functions under thecontrol of software including an operating system and any appropriateapplications software. The CPU 604 may include one or more processors608, such as a processor from the INTEL X86 family of microprocessors.In some cases, processor 608 can be specially designed hardware forcontrolling the operations of the network device 600. In some cases, amemory 606 (e.g., non-volatile RAM, ROM, etc.) also forms part of theCPU 604. However, there are many different ways in which memory could becoupled to the system.

The interfaces 602 are typically provided as modular interface cards(sometimes referred to as “line cards”). Generally, they control thesending and receiving of data packets over the network and sometimessupport other peripherals used with the network device 600. Among theinterfaces that may be provided are Ethernet interfaces, frame relayinterfaces, cable interfaces, DSL interfaces, token ring interfaces, andthe like. In addition, various very high-speed interfaces may beprovided such as fast token ring interfaces, wireless interfaces,Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSIinterfaces, POS interfaces, FDDI interfaces, WIFI interfaces, 3G/4G/5Gcellular interfaces, CAN BUS, LoRA, and the like. Generally, theseinterfaces may include ports appropriate for communication with theappropriate media. In some cases, they may also include an independentprocessor and, in some instances, volatile RAM. The independentprocessors may control such communications intensive tasks as packetswitching, media control, signal processing, crypto processing, andmanagement. By providing separate processors for the communicationsintensive tasks, these interfaces allow the CPU 604 to efficientlyperform routing computations, network diagnostics, security functions,etc.

Although the system shown in FIG. 6 is one specific network device ofthe present technologies, it is by no means the only network devicearchitecture on which the present technologies can be implemented. Forexample, an architecture having a single processor that handlescommunications as well as routing computations, etc., is often used.Further, other types of interfaces and media could also be used with thenetwork device 600.

Regardless of the network device's configuration, it may employ one ormore memories or memory modules (including memory 606) configured tostore program instructions for the general-purpose network operationsand mechanisms for roaming, route optimization and routing functionsdescribed herein. The program instructions may control the operation ofan operating system and/or one or more applications, for example. Thememory or memories may also be configured to store tables such asmobility binding, registration, and association tables, etc. The memory606 could also hold various software containers and virtualizedexecution environments and data.

The network device 600 can also include an application-specificintegrated circuit (ASIC), which can be configured to perform routingand/or switching operations. The ASIC can communicate with othercomponents in the network device 600 via the connection 610, to exchangedata and signals and coordinate various types of operations by thenetwork device 600, such as routing, switching, and/or data storageoperations, for example.

FIG. 7 illustrates an example computing device architecture 700 of anexample computing device which can implement the various techniquesdescribed herein. The components of the computing device architecture700 are shown in electrical communication with each other using aconnection 705, such as a bus. The example computing device architecture700 includes a processing unit (CPU or processor) 710 and a computingdevice connection 705 that couples various computing device componentsincluding the computing device memory 715, such as read only memory(ROM) 720 and random access memory (RAM) 725, to the processor 710.

The computing device architecture 700 can include a cache of high-speedmemory connected directly with, in close proximity to, or integrated aspart of the processor 710. The computing device architecture 700 cancopy data from the memory 715 and/or the storage device 730 to the cache712 for quick access by the processor 710. In this way, the cache canprovide a performance boost that avoids processor 710 delays whilewaiting for data. These and other modules can control or be configuredto control the processor 710 to perform various actions. Other computingdevice memory 715 may be available for use as well. The memory 715 caninclude multiple different types of memory with different performancecharacteristics. The processor 710 can include any general purposeprocessor and a hardware or software service, such as service 1 732,service 2 734, and service 3 736 stored in storage device 730,configured to control the processor 710 as well as a special-purposeprocessor where software instructions are incorporated into theprocessor design. The processor 710 may be a self-contained system,containing multiple cores or processors, a bus, memory controller,cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing device architecture 700,an input device 745 can represent any number of input mechanisms, suchas a microphone for speech, a touch-sensitive screen for gesture orgraphical input, keyboard, mouse, motion input, speech and so forth. Anoutput device 735 can also be one or more of a number of outputmechanisms known to those of skill in the art, such as a display,projector, television, speaker device, etc. In some instances,multimodal computing devices can enable a user to provide multiple typesof input to communicate with the computing device architecture 700. Thecommunications interface 740 can generally govern and manage the userinput and computing device output. There is no restriction on operatingon any particular hardware arrangement and therefore the basic featureshere may easily be substituted for improved hardware or firmwarearrangements as they are developed.

Storage device 730 is a non-volatile memory and can be a hard disk orother types of computer readable media which can store data that areaccessible by a computer, such as magnetic cassettes, flash memorycards, solid state memory devices, digital versatile disks, cartridges,random access memories (RAMs) 725, read only memory (ROM) 720, andhybrids thereof. The storage device 730 can include services 732, 734,736 for controlling the processor 710. Other hardware or softwaremodules are contemplated. The storage device 730 can be connected to thecomputing device connection 705. In one aspect, a hardware module thatperforms a particular function can include the software component storedin a computer-readable medium in connection with the necessary hardwarecomponents, such as the processor 710, connection 705, output device735, and so forth, to carry out the function.

For clarity of explanation, in some instances the present technology maybe presented as including individual functional blocks includingfunctional blocks comprising devices, device components, steps orroutines in a method embodied in software, or combinations of hardwareand software.

In some embodiments the computer-readable storage devices, mediums, andmemories can include a cable or wireless signal containing a bit streamand the like. However, when mentioned, non-transitory computer-readablestorage media expressly exclude media such as energy, carrier signals,electromagnetic waves, and signals per se.

Methods according to the above-described examples can be implementedusing computer-executable instructions that are stored or otherwiseavailable from computer readable media. Such instructions can comprise,for example, instructions and data which cause or otherwise configure ageneral purpose computer, special purpose computer, or special purposeprocessing device to perform a certain function or group of functions.Portions of computer resources used can be accessible over a network.The computer executable instructions may be, for example, binaries,intermediate format instructions such as assembly language, firmware, orsource code. Examples of computer-readable media that may be used tostore instructions, information used, and/or information created duringmethods according to described examples include magnetic or opticaldisks, flash memory, USB devices provided with non-volatile memory,networked storage devices, and so on.

Devices implementing methods according to these disclosures can comprisehardware, firmware and/or software, and can take any of a variety ofform factors. Some examples of such form factors include general purposecomputing devices such as servers, rack mount devices, desktopcomputers, laptop computers, and so on, or general purpose mobilecomputing devices, such as tablet computers, smart phones, personaldigital assistants, wearable devices, and so on. Functionality describedherein also can be embodied in peripherals or add-in cards. Suchfunctionality can also be implemented on a circuit board among differentchips or different processes executing in a single device, by way offurther example.

The instructions, media for conveying such instructions, computingresources for executing them, and other structures for supporting suchcomputing resources are means for providing the functions described inthese disclosures.

Although a variety of examples and other information was used to explainaspects within the scope of the appended claims, no limitation of theclaims should be implied based on particular features or arrangements insuch examples, as one of ordinary skill would be able to use theseexamples to derive a wide variety of implementations. Further andalthough some subject matter may have been described in languagespecific to examples of structural features and/or method steps, it isto be understood that the subject matter defined in the appended claimsis not necessarily limited to these described features or acts. Forexample, such functionality can be distributed differently or performedin components other than those identified herein. Rather, the describedfeatures and steps are disclosed as examples of components of systemsand methods within the scope of the appended claims.

Claim language reciting “at least one of” a set indicates that onemember of the set or multiple members of the set satisfy the claim. Forexample, claim language reciting “at least one of A and B” means A, B,or A and B.

What is claimed is:
 1. A method comprising: receiving information on oneor more software vulnerabilities from one or more external feeds;identifying, from a services catalog, one or more vulnerable serviceinstances supported by a service mesh, the one or more vulnerableservice instances identified as having one or more softwarevulnerabilities based on the received information, wherein the servicescatalog comprises data associated with one or more service instancessupported by the service mesh; and providing at least one notificationto at least one sidecar proxy associated with at least one vulnerableservice instance of the one or more vulnerable service instances, the atleast one notification comprising one or more criteria associated withone or more software vulnerabilities of the at least one vulnerableservice instance.
 2. The method of claim 1, wherein the one or morecriteria comprise one or more criticality levels associated with the oneor more software vulnerabilities of the at least one vulnerable serviceinstance.
 3. The method of claim 2, wherein the one or more criticalitylevels are based on a common vulnerability scoring system (CVSS).
 4. Themethod of claim 1, wherein the one or more criteria comprise one or morecategories associated with the one or more software vulnerabilities ofthe at least one vulnerable service instance.
 5. The method of claim 1,wherein the at least one notification further comprises an instructionto the at least one sidecar proxy to trip a circuit breaker associatedwith the at least one vulnerable service instance.
 6. The method ofclaim 5, wherein the instruction is based on the one or more criteriaand one or more destination policies for the at least one vulnerableservice instance.
 7. The method of claim 5, wherein tripping the circuitbreaker prevents access to the at least one vulnerable service instanceand causes requests to access the at least one vulnerable serviceinstance to be returned with a message indicating that the at least onevulnerable service instance is unavailable.
 8. The method of claim 1,further comprising reporting the one or more software vulnerabilities ofthe at least one vulnerable service instance to an orchestration systemfor the service mesh.
 9. The method of claim 1, wherein the one or moreexternal feeds comprise one or more cloud consortia, blockchains, orProduct Security Incident Response Team (PSIRT) bulletin boards.
 10. Themethod of claim 1, further comprising determining a fix to the one ormore software vulnerabilities of the at least one vulnerable serviceinstance and providing the fix to the at least one sidecar proxy. 11.The method of claim 10, wherein the fix comprises a version of the atleast one service instance unaffected by the one or more softwarevulnerabilities of the at least one vulnerable service instance.
 12. Themethod of claim 10, wherein the fix comprises a version of the at leastone vulnerable service instance including a patch for the one or moresoftware vulnerabilities of the at least one vulnerable serviceinstance.
 13. The method of claim 1, wherein the data associated withone or more service instances in the services catalog comprises one ormore of an operating system version, software version, or dependencypackages of the one or more service instances.
 14. A system, comprising:one or more processors; and a non-transitory computer-readable storagemedium containing instructions which, when executed on the one or moreprocessors, cause the one or more processors to perform operationsincluding: receiving information on one or more software vulnerabilitiesfrom one or more external feeds; identifying, from a services catalog,one or more vulnerable service instances supported by a service mesh,the one or more vulnerable service instances identified as having one ormore software vulnerabilities based on the received information, whereinthe services catalog comprises data associated with one or more serviceinstances supported by the service mesh; and providing at least onenotification to at least one sidecar proxy associated with at least onevulnerable service instance of the one or more vulnerable serviceinstances, the at least one notification comprising one or more criteriaassociated with one or more software vulnerabilities of the at least onevulnerable service instance.
 15. The system of claim 14, wherein the oneor more criteria comprise one or more criticality levels associated withthe one or more software vulnerabilities of the at least one vulnerableservice instance.
 16. The system of claim 15, wherein the one or morecriticality levels are based on a common vulnerability scoring system(CVSS).
 17. The system of claim 14, wherein the one or more criteriacomprise one or more categories associated with the one or more softwarevulnerabilities of the at least one vulnerable service instance.
 18. Thesystem of claim 14, wherein the at least one notification furthercomprises an instruction to the at least one sidecar proxy to trip acircuit breaker associated with the at least one vulnerable serviceinstance.
 19. The system of claim 14, wherein the operations furthercomprise: reporting the one or more software vulnerabilities of the atleast one vulnerable service instance to an orchestration system for theservice mesh.
 20. The system of claim 14, wherein the operations furthercomprise: determining a fix to the one or more software vulnerabilitiesof the at least one vulnerable service instance and providing the fix tothe at least one sidecar proxy.